1. Avant-propos

Architecte
Figure 1. Analyser et Concevoir

Nous allons vous apprendre dans ce cours des techniques pour Analyser et Concevoir des Systèmes d'Information…

Nous nous servirons du parallèle avec la réalisation d’une oeuvre d’architecte (comme une maison, cf. [Architecte]).

1.1. A qui est destiné ce document?

Les étudiants du DUT informatique, mes collègues enseignants qui cherchent un document de référence accessible, et … moi-même (pour organiser mes notes diverses)!

1.2. A qui il n’est pas destiné?

Si vous appartenez à une de ces catégories, ce document n’est pas pour vous :

  • vous cherchez un livre de référence

  • vous voulez vous perfectionner

  • vous souhaitez préparer une certification

1.3. Historique

Ce document est la compilation de plusieurs années d’enseignement …

Vous trouverez en référence (cf. Bibiliographie) les ouvrages et autres documents utilisés.

Je tiens à remercier mes collègues qui m’ont aidé dans mon entreprise :

1.4. Sur l’auteur

1.5. Comment lire ce document?

Ce document a été réalisé de manière à être lu de préférence dans sa version électronique (au format PDF), ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.

Warning Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, et c’est votre punition pour avoir utilisé du papier au lieu du support électronique!

1.5.1. Conventions typographiques

J’ai utilisé un certain nombre de conventions personnelles pour rendre ce document le plus agréable à lire et le plus utile possible, grâce notamment à la puissance d’AsciiDoc :

  • Des mises en formes particulières concernent les noms de personnalités (e.g., Jean-Michel Inglebert), etc.

  • Les références bibliographiques présentées en fin de document (cf. Bibliographie).

  • Tous les flottants (figures, tableaux, définitions, etc.) sont listés à la suite de la table des matière.

  • Les termes anglais (souvent incontournables) sont repérés en italique, non pas pour indiquer qu’il s’agit d’un mot anglais, mais pour indiquer au lecteur que nous employons

1.6. Pourquoi parler de "document"?

Parce que j’ignore la version que vous êtes en train de lire. A partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc :

  • Une version pour le web (Moodle) au format html

  • Une version pour présentation en amphi au format présentation

  • Une version pour impression au format pdf

Tip Si vous êtes curieux sur la production de document "par programmation", je vous invite à lire la section dédiée.

1.7. Utilisation et autres mentions légales

Les images qui ne sont pas libres de droit contiennent un lien vers les sites où je les ai "empruntées".

Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham. La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert. Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant ici.

Partie 1 : Généralités

1. Place dans la formation

  • Ce module est central

    • (presque) tous les autres tournent autour (cf. [Central])

    • Fil conducteur

  • Le contenu est « flou »

    • Le PPN ne décrit que les compétences

    • Très variable en contenu

    • Soyez critiques!

2. Organisation

  • 2 intervenants permanents

  • 2 intervenants supplémentaires en TD/TP

  • Découpage Cours / TD / TP

  • 3 semestres + 1

  • Pour ce semestre (S1) :

    • 16 semaines (devoir en 8ème semaine environ)

    • 1H30 de Cours toutes les 2 semaines

    • 1H30 de TD chaque semaine

3. Généralités

  • Supports

    • disponibles sur Moodle

    • Après ou avant les cours

      • Après (pdf) pour ce genre de supports

      • Avant (distribués en cours) pour les supports « techniques »

Warning uniquement une aide à vos notes personnelles

  • Outils

    • UML

    • WinDesign

4. Objectifs

Comme tout le reste du programme enseigné au DUT, ce cours est une adaptation du PPN :

  • Les organisations et leurs Systèmes d’Information

  • Le Génie Logiciel et la façon de concevoir un système de qualité

  • Les démarches/méthodes (Merise), notations (UML ) et outils nécessaires aux futurs métiers qui vous attendent

Le module ACSI se décompose en deux parties principales (Unités de Formation) :

  • Modélisation des Systèmes d’Information

  • Techniques Complémentaires de Production Logicielles

4.1. Modélisation des Systèmes d’Information

  • Objectifs :

    • Connaître les outils de modélisation des systèmes d’information

    • Connaître un atelier de génie logiciel

  • Compétences visées :

    • Produire une spécification opérationnelle

  • Pré-requis :

    • Algorithmique

    • Théorie des ensembles, relations, logique

    • Calcul des propositions et des prédicats

  • Programme :

    • Organisations et systèmes d’information

    • Langages de modélisation

    • Méthodes d’analyse et de conception orientée objet

    • Initiation à l’utilisation d’un Atelier de Génie Logiciel

    • Etude de cas

Note Ces éléments sont tirés du PPN.

4.2. Techniques Complémentaires de Production Logicielles

  • Objectifs :

    • Connaître les principes de conception de l’Interface Homme-Machine

    • Connaître les principes de mise en œuvre de la qualité logicielle

  • Compétences visées :

    • Mettre en œuvre les principes de conception de l’I.H.M.

    • Mettre en œuvre une approche qualité dans le processus de production du logiciel

  • Pré-requis :

    • Expérience en programmation et en modélisation des systèmes d’information

  • Programme :

    • Qualité du logiciel : objectif du génie logiciel ; assurance qualité, normes, gestion des

    • projets logiciels et documentation, cycle de vie du logiciel, architecture logicielle

    • Principes et techniques de base des tests : familles et niveaux de tests, outil de tests

    • Interaction homme-machine : prise en compte de l’utilisateur, conception de l’I.H.M.,

    • composants graphiques, choix et recommandations ergonomiques, I.D.E.

Note Ces éléments sont tirés du PPN.

4.3. Interactions avec les autres cours

  • Programmation

  • Bases de données

  • Gestion de projet

  • …

Note

Voici un exemple :

  • en S1/S2 : tests sur requêtes SQL

  • en S3 : dvpt site Web dynamique

Place Centrale
Figure 2. Place centrale du module d’ACSI

4.4. Concrètement

  • Plusieurs matières

  • Plusieurs intervenants

  • Plusieurs supports de cours

    • Organisation

    • Merise

    • UML

    • Systèmes d’Information

    • Génie Logiciel

  • Nombreux exercices

    • sujets

    • corrections

  • Très nombreux supports Internet

Warning

Rien ne vaut la pratique elle-même!

5. Fondements

Pour mener à bien le développement d’un système informatique industriel ou commercial, on ne peut pas improviser. Il s’agit d’un travail impliquant un grand nombre de personnes, des enjeux financiers souvent énormes. Le but de ce cours est de vous faire prendre conscience de cet état de fait autant que de vous donner les différentes techniques liées à cette activité. Au nom de quoi pouvez-vous avoir confiance dans les conseils présentés dans ce cours? Il ne faut pas justement! Il vous faut sans arrêt questionner, remettre en cause les idées reçues. Néanmoins, les éléments de ce cours ne sortent pas de l’imagination fertile de son auteur. Je m’inspire principalement de ceux qui ont l’expérience en la matière. C’est pourquoi vous trouverez un grand nombre de références et d’informations pour aller plus loin (généralement des URLs).

L’objectif de ce cours est d’aborder la problématique du développement raisonné (de qualité, sûr, rapide, pas cher, etc.) de systèmes d’information. La méthode choisie est celle des études de cas et des applications concrètes.

Les concepts abordés peuvent se classer en différents niveaux [gram86] :

stratégies

règles de comportement général guidant les choix du développeur (par exemple, obtenir le plus rapidement possible un énoncé exécutable relève de la stratégie "prototyper").

tactiques

décrivent des étapes logiques de développement conduisant à un énoncé possédant certaines propriétés (par exemple, passer d’un énoncé imprécis à un énoncé totalement défini relève de la tactique "spécifier").

paradigmes

sont des étapes élémentaires de la construction d’un programme (par exemple, expliciter une entité par un nom et une définition informelle revient à appliquer le paradigme "désigner").

5.1. Stratégies

On vous parlera ici de méthodes, de cycle de vie, de gestion de projet. Mais nous aborderons cela bien plus tard car dans un premier temps cela va être à la fois rébarbatif et très loin de vos préoccupations.

Pour l’instant retenons des principes simples :

  • Comprendre

  • S’organiser

  • Modéliser

  • S’adapter

5.1.1. Comprendre

Théoricien : individu qui n’est pas de votre avis.

découvert dans Le Lexique d'Habrias
— Auguste Detoeuf

Le problème, l’environnement, les outils à maîtriser, la solution attendue, le domaine métier, etc.

5.1.2. S’organiser

Vingt fois sur le métier remettez votre ouvrage : Polissez-le sans cesse et le repolissez ; Ajoutez quelquefois, et souvent effacez.

— N. Boileau

Dans les méthodes agiles on parle de "sprint 0". Il est important de bien s’organiser avant de foncer tête baissée dans le travail à proprement parlé.

Voici quelques éléments importants à aborder :

Démarche globale

Quelle démarche allez-vous mettre en oeuvre (Merise, RUP, Agile, personnelle, …)?

Rôles

Qui va faire quoi?

Environnement

Quels outils allez-vous utiliser (modélisation, analyse, développement, test, documentation)?

Versionnage

Il est très important, surtout dans un travail collaboratif, de bien utiliser un outil de gestion de version. Que ce soit pour le code (facile), la documentation (moins évident) ou les modèles (très difficile). Pour le code, le nombre de systèmes disponibles vous empêche d’avoir une excuse (git,Subversion,Mercury).

5.1.3. Modéliser

Ce que l’on conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément.

— N. Boileau

Pour s’abstraire.

5.1.4. S’adapter

Se mettre à jour des techniques. Adapter sa façon de procéder au contexte (au poste que l’on occupe par exemple). Voir [feedback].

5.2. Tactiques

Liste de tactiques :

  • spécifier

  • décomposition (d’un problème en sous-problème)

  • itération

  • induction (construire un énoncé récursif)

  • approximation (organiser la résolution d’un problème en étudiant d’abord un nouveau problème, considéré comme plus simple)

  • généralisation (formuler et résoudre le problème à un niveau d’abstraction plus général pour permettre ensuite un plus grand nombre d’identifications)

  • réutilisation (exploiter au mieux tout travail déjà fait, cf. aussi [DRY])

5.3. Paradigmes

Liste de paradigmes :

  • désigner

  • typer (décrire les proriétés pertinentes d’une entité)

  • affaiblir (transformer un énoncé pour en réduire la complexité)

  • renforcer (compléter un énoncé par des contraintes supplémentaires)

  • décomposer par cas (lorsqu’on distingue plusieurs traitements suivant les données du problème à un endroit donné)

  • sérialiser (pour définir un résultat, utiliser un résultat intermédiaire x à partir des données, puis exprimer le résultat à partir de x)

  • répartir (définir séparément un certain nombre de sous-résultats, qu’il s’agit ensuite de composer entre eux pour obtenir le résultat attendu)

  • identifier (identifier deux problèmes consiste à reconnaître leur identité au-delà des différences de forme de leurs énoncés)

  • paramétrer (faire abstraction des valeurs particulières de certaines entités, parce qu’elles ne sont pas pertinentes pour l'élaboration de la solution visée)

  • représenter (choisir, pour certaines entités, les types, les relations et le moyen d’expression adéquats)

Les tactiques sont des compositions de paradigmes. Ainsi, la mise en oeuvre de la tactique d’approximation consiste à appliquer le paradigme affaiblir, et le cas échéant le paradigme renforcer pour revenir au problème posé.

5.4. Le Manifeste Agile

Le Manifeste Agile (Agile Manifesto [HighsmithFowler2001]) est un ensemble de principes (voir aussi [1030005] pour une analyse plus récente).

Principe : Satisfaction

Notre plus haute priorité est de satisfaire le client en lui livrant rapidement, et ce, de façon continue un logiciel de qualité.

Principe : Améliorations

À intervalles réguliers, l'équipe réfléchit sur une façon de devenir plus efficace, puis adapte et ajuste son comportement en conséquence.

Partie 2 : Merise

Plan de cette partie :

Note: Dans nos enseignements de DUT Informatique, cette partie est abordée en 3ème semestre.

1. Pourquoi une méthode ?

  • On peut faire ce qu’on veut :

    • si on est seul

    • si on a le temps

    • si on n’a pas de comptes à rendre

    • si les erreurs n’ont pas de conséquences

  • Pour tout le reste

    • besoin de communiquer

    • besoin de s’abstraire de la complexité

    • besoin de rendre des comptes

2. Pourquoi MERISE ?

Ce qu’on peut dire de Merise :

  • méthode très utilisée en France

  • des générations de programmeurs l’ont apprise

  • elle permet donc de servir de référence pour les autres approches

3. Concepts clés et principes de bases

  • Approche systémique

  • Différents niveaux d’abstraction

  • Différentes considérations ("vues")

  • Démarche globale

3.1. Approche systémique

On complète Descartes :

  • logique ternaire ou conjonctive (qui relie) plutôt que logique binaire ou disjonctive (qui sépare)

  • centrée sur le but à atteindre (finalité) plutôt que sur la recherche des causes (causalité)

  • relationnelle et globale plutôt qu’analytique

  • orientée par le présent/futur (prospective) plutôt que par le passé/présent (déterminisme)

  • ouverte sur la diversité des réalités et la pluralité des solutions plutôt que sur la quête de certitudes et de réponses "universelles"

  • propice à l'émergence de la nouveauté et à l’invention (moins réductrice)

3.2. Différents niveaux d’abstraction

Conceptuel

  • quoi?

Organisationnel

  • d’où?

  • qui?

  • quand?

Logique

  • quand? où? comment?

  • indépendamment de l'"implémentation"

Technique

  • comment?

  • le concret

3.3. Différentes considérations ("vues")

Flux

  • ce qui circule

  • architecture

Traitements

  • dynamique

  • comment le système se comporte

Données

  • statique

  • ce qui est manipulé

3.4. Démarche globale

Intersection entre vues et niveaux

Table 1. La carte de base
Flux Traitements Données

Conceptuel

Organisationel

Logique

Technique

Démarche par étape

  • Le schéma directeur

  • L'étude préalable

  • L'étude détaillée

  • La réalisation

  • La mise en œuvre

  • La maintenance

Note On verra ça plus tard

4. Les flux

4.1. Notation

  • cerner le domaine qui nous intéresse

    Domaine

  • identifier les échanges

    • flux

      Flux

    • acteurs

Acteur

4.2. Exemples

Exemple de flux entre acteur et domaine
Figure 3. Exemple de flux entre acteurs
Un exemple
Figure 4. Exemple plus complet
Version textuelle
Figure 5. Représentation en matrice

4.3. Exercice

4.3.1. Enoncé

  • Une agence de location de voitures veut informatiser la gestion des locations.

  • Lorsqu’un client se présente à l’accueil, il précise le type de voiture désiré ainsi que la durée de location.

  • L’accueil vérifie si la location est possible et donne la réponse au client.

  • Si c’est le cas, la facture est éditée et donnée au client.

  • Celui-ci doit payer immédiatement.

  • Le paiement et la facture sont transmis au service comptable.

  • L’accueil transmet alors la demande au garage.

  • Ce dernier va préparer le véhicule demandé et le mettre à disposition du client.

4.3.2. Solution

Agence de location

  • 1 : demande de location

  • 2 : acceptation ou refus

  • si acceptation :

    • 3 : facture

    • 4 : paiement

    • 5 : détail location + paiement

    • 6 : détail demande

    • 7 : véhicule

4.4. Règles de conception

Pas de flux qui boucle sur un même acteur

  • Les flux ne sont qu’entre 2 acteurs distincts.

  • Si l’on désire représenter des flux à l’intérieur d’un acteur, c’est que l’acteur doit être décomposé en plusieurs.

Pas de flux sur soi-même

Pas de flux entre acteurs externes

Ces flux ne nous intéressent pas car ils ne concernent pas le domaine à informatiser.

Pas de flux sur soi-même

Note Dans de rares cas, on représentera tout de même les flux entre certains acteurs externes pour une meilleure compréhension du système.
Pas de flux bidirectionnels

La représentation doit donner lieu à 2 flux distincts.

Pas de flux sur soi-même

4.5. Erreurs classiques

  • un acteur n’est pas un objet

    Acteur n’est pas Objet

  • un flux n’est pas un mouvement d’acteur

Flux n’est pas déplacement

4.6. Modèle Conceptuel des Flux

  • Pas de représentation des acteurs internes

  • Juste le domaine et ses échanges avec les acteurs externes

  • Vue "boîte noire"

Table 2. MCF
Flux Traitements Données

Conceptuel

MCF

Organisationel

Logique

Technique

4.7. Modèle Organisationnel des Flux

  • Représentation des acteurs internes

  • De leurs échanges avec les acteurs externes

  • Vue "boîte blanche"

  • Doit être cohérent avec le MCF correspondant

Table 3. MOF
Flux Traitements Données

Conceptuel

MCF

Organisationel

MOF

Logique

Technique

4.8. Exercice : gestion de Carte Bleue

  • Le demandeur désirant obtenir une carte bleue doit en faire la demande auprès d’un employé de son agence. La carte bleue n’est accordée que si le demandeur est un client de l’agence.

  • Chaque jour, un employé de l’agence transmet au centre de gestion des cartes bleues les demandes des clients. Dès que le chef d’agence reçoit la carte bleue en provenance du centre (en général 4 jours après la demande), il adresse au client un avis de mise à disposition et un avis de prélèvement de la cotisation annuelle.

  • Le client vient alors retirer sa carte auprès du chef d’agence. Si au bout de 2 mois la carte n’a pas été retirée, elle est détruite.

4.9. Correction : gestion de Carte Bleue

  1. Détermination des acteurs externes

  2. Réalisation du MCF

  3. Détermination des acteurs internes

  4. Réalisation du MOF

Note MCF
1. Demande CB
2. Refus
3. Demande Groupée CB
4. Livraison CB
5. Avis de mise à disposition et avis de prél.
6. Retrait de la carte
Note MOF
1. Demande CB
2. Refus
3. Demande Groupée CB
4. Livraison CB
5. Avis de mise à disposition et avis de prél.
6. Retrait de la carte

5. Les traitements

5.1. Objectifs

  • Déterminer des processus

  • A partir des acteurs et des flux d’information

  • Notion de rôles de gestion

  • Concepts

    • les événements

    • les opérations

    • les résultats

    • la synchronisation

5.2. Diagrammes

Modèle Conceptuel de Traitement (MCT)

Répondre au QUOI?

Modèle Organisationnel de Traitement (MOT)

Répondre au QUI fait QUOI et QUAND?

Table 4. MCT et MOT
Flux Traitements Données

Conceptuel

MCT

Organisationel

MOT

Logique

Technique

5.3. Notation

  • événements

    Exemple d'événement

  • synchronisation

    Notation de synchronisation

  • opération

    Notation d’une opération

  • Règles d’émission

    Règles d'émission

  • Résultats

Exemple d'événement

5.3.1. Modèle Conceptuel de Traitement

Eléments importants

  • Fiches de poste

    • Tâches

      • Evénements déclencheur

      • Actions

      • Résultats

  • Opération

  • Événements déclencheurs

  • Synchronisation éventuelle (règles logiques)

  • Résultats

  • Règles d’émission

Flux Traitements Données

Conceptuel

MCT

Organisationel

MOT

Logique

Technique

Exemples
Opération complète
Figure 6. Opération complète
Opération complète
Figure 7. Opération complète
Opération complète
Figure 8. Opération complète
Opération complète
Figure 9. Opération complète
Récapitulatif de la démarche (MCT)

  1. Identifier les postes

  2. Définir les tâches

  3. Déterminer les opérations

  4. Associer les événements déclencheurs

  5. Déterminer les résultats

  6. Décrire les règles d’émission

Règles de bonne conception (MCT)

  • Regroupement de tous les traitements effectués dès l’arrivée d’un événement

  • Ne pas tenir compte de l’organisation interne du domaine étudié (répartition du travail entre acteurs internes)

  • Seule l’attente d’événements externes (=flux externes) justifie le découpage en plusieurs opérations

  • 2 opérations consécutives liées exclusivement par des flux internes doivent être fusionnées.

  • Réutiliser les acteurs externes, les autres domaines et les flux externes trouvés dans le MCF

Evénements déclencheurs
Evénement externe

Arrivée d’une cde, dde du client…

Evénement temporel

18h, tous les lundis matin…

Evénement interne

résultat d’une opération précédente

Synchronisation

Opérateurs :

  • ET

  • OU

  • NON

  • ( )

  • combinaisons multiples

Note

  • Pour 1 événement déclencheur, pas de synchronisation.

  • Pour 2 événements déclencheurs, souvent un seul opérateur.

  • A partir de 3, les événements peuvent être renommés (lettres).

Actions

  • Types d’actions :

    action sur un objet

    création, lecture, modification, suppression

    action résultat

    impression, …

  • Conditions

    • une action peut être soumise à condition

Règles d'émission
Règle d'émission

résultat de l’action

Nombre

1 ou plusieurs

Note

  • S’il n’y a qu’une règle d'émission, elle est souvent omise, ou son nom est TOUJOURS.

  • Une règle d'émission peut utiliser une condition.

Résultats

  • Evénement résultat externe

    • impression, mail, coup de téléphone…

  • Evénement résultat interne

    • déclencheur d’une opération

    • changement d'état d’un objet

Note Une opération possède au moins un événement résultat par règle d'émission. Un résultat externe est toujours dirigé vers un acteur externe ou un autre domaine.
Exercice

  • Lorsqu’un client envoie un bon de commande, il faut vérifier, pour chacun des articles, si le stock est suffisant pour la quantité commandée :

    • si c’est le cas, on enregistre la date de livraison, on met à jour le stock et on imprime un bon de livraison pour le service Livraison;

    • sinon le stock à réapprovisionner est incrémenté de la quantité commandée.

Exemple de MCT

Exemple de MCT

5.3.2. Modèle Organisationnel de Traitement

Eléments importants

  • Prise en compte de l’organisation interne

  • Cerne l’activité de

    • chaque poste de travail (informatique ou non),

    • chaque service

  • Prise en compte

    • Du « planning »

    • du type de ressources (manuel, automatisé),

    • du type de support (document écrit, magnétique etc.)

Flux Traitements Données

Conceptuel

MCT

Organisationel

MOT

Logique

Technique

Exemples de MOT

Exemple de MOT

Règles de bonne conception d’un MOT

  • Examiner les traitements effectués par chaque acteur interne lorsqu’il reçoit un flux

  • Une tâche = un ensemble ininterrompu d’actions effectuées par un même acteur interne

  • Un MOT représente un processus c’est à dire un ensemble de tâches consécutives concourant à un même but

  • Les événements initiaux déclenchant un processus sont, soit des flux externes, soit des événements temporels

Exemple 1

  • Lorsqu’un agent d’une compagnie d’assurances automobiles reçoit une déclaration d’accident de la part d’un assuré, il vérifie tout d’abord la situation de ce dernier.

  • Si l’assuré n’est pas couvert pour ce type d’accident alors l’agent lui envoie un avis de rejet.

  • Tous les soirs à 18h, un traitement automatique édite les avis de sinistre de la journée (ces avis correspondent aux déclarations d’accident du jour pour les assurés couverts). Ces avis sont expédiés par l’agent au siège social de la compagnie d’assurance.

  • Le siège social désigne alors un expert pour chaque sinistre et envoie les coordonnées des experts désignés à l’agent d’assurance. Ce dernier envoie alors une convocation manuscrite à chaque expert.

  • Lorsque l’agent d’assurance a reçu le rapport de l’expert et la facture de l’assuré (cette facture a été produite par le garage qui a effectué les réparations sur le véhicule accidenté et a été ensuite donné à l’assuré propriétaire du véhicule), il peut régler le sinistre en envoyant un chèque de remboursement à l’assuré.

Exemple de MCT

Exemple de MCT

Exemple de MOF

Exemple de MOF

Exemple de MOT

Exemple de MOT

Exemple 2

  • A partir des demandes d’approvisionnement établies par le service commercial, le service des achats envoie des demandes de prix aux fournisseurs possibles.

  • Les fournisseurs envoient des offres de prix au service achat. Ce dernier choisit alors un fournisseur particulier (au plus tard 10 jours après l’envoi des offres) et lui envoie un bon de commande. Une copie est conservée en vue de la réception.

  • Quand la livraison arrive (généralement 2 jours après le choix du fournisseur), le service achat contrôle quantitativement et qualitativement la marchandise. La livraison est renvoyée en bloc si l’un des contrôles est négatif.

  • Les contrôles satisfaisants aboutissent à l’entrée en stock des articles. Dans ce cas, le service achat établit alors le bon à payer aux services financiers. Quand les services financiers reçoivent la facture du fournisseur (généralement 3 jours après la livraison), ils vérifient la correspondance avec le bon à payer et émettent le chèque de paiement.

  • A partir des demandes d’approvisionnement établies par le service commercial, le service des achats envoie des demandes de prix aux fournisseurs possibles.

  • Les fournisseurs envoient des offres de prix au service achat. Ce dernier choisit alors un fournisseur particulier (au plus tard 10 jours après l’envoi des offres) et lui envoie un bon de commande. Une copie est conservée en vue de la réception.

  • Quand la livraison arrive (généralement 2 jours après le choix du fournisseur), le service achat contrôle quantitativement et qualitativement la marchandise. La livraison est renvoyée en bloc si l’un des contrôles est négatif.

  • Les contrôles satisfaisants aboutissent à l’entrée en stock des articles. Dans ce cas, le service achat établit alors le bon à payer aux services financiers. Quand les services financiers reçoivent la facture du fournisseur (généralement 3 jours après la livraison), ils vérifient la correspondance avec le bon à payer et émettent le chèque de paiement.

Exemple de MOT

5.3.3. Modélisation du futur Système

Enchainements

MOT/MOF Futurs

  • Degré d’automatisation

    • Automatisée : aucune intervention humaine

    • Conversationnelle (ou Interactive) : utilisation de l’informatique par l’humain

    • Manuelle : aucune intervention informatique

  • Délai de réponse

    • Immédiat : dès l’arrivée de l’événement déclencheur

    • Différé : après l’arrivée (délai sur décision ou chrono)

  • Mode de fonctionnement

    • Unitaire : la tâche s’effectue à chaque flux entrant

    • Par Lot : plusieurs flux d’entrée avant lancement

Tip
Certaines combinaisons plus fréquentes

  • CIU (dialogue)

  • ADL (batch)

Tip
Certaines implications

  • L→D

  • I→U

  • IL rare

Tip
Possibilité de compléter les informations

  • Durée/Volume des tâches

  • Exemple : 20 enr./semaine, 6 mn/tâche, …

Exemple de tâche de MCT futur

Exemple de tâche

5.4. Définitions (récapitulatif)

Définition : Flux

Représentation d’un échange d’informations entre deux acteurs du domaine étudié ex: livraison, paiement

Définition : Acteurs

  • Composants du système étudié (acteurs internes) ou ayant une relation avec le système étudié (acteurs externes)

  • ex: étudiant, client, comptable

Définition : Evénement

  • Fait susceptible de déclencher une opération

  • ex: commande, échéance (date)

Définition : Opération

  • Ensemble d’actions (non interruptibles) conditionnées par aucun agent extérieur autre que l’événement déclencheur

  • ex: prise en charge d’une demande

Définition : Poste de travail

  • Centre d’activités élémentaires regroupant zéro, une ou plusieurs personnes, utilisant du matériel ou pas, faisant l’objet d’une ou plusieurs occurrences sur le terrain.

Définition : Tâche

  • Ensemble homogène d’activités élémentaires résultant de la décomposition d’une opération conceptuelle.

  • Est associée à un poste de travail ;

  • A un niveau d’automatisation :

    • Manuelle (M),

    • Interactive ou Conversationnelle ©,

    • Automatique (A) ;

  • A un délai de réponse :

    • Immédiat (I),

    • Différé (D) ;

  • A un fonctionnement :

    • Unitaire (U) ou

    • par Lot (L) ;

6. Les niveaux logiques et techniques?

Pourquoi a-t’on décidé de "zapper" ces niveaux…

7. Les données

8. Références utiles pour cette partie

Partie 3 : SI

Partie 4 : SI et Organisations

Partie 5 : UML

Partie 6 : Conception des IHM

Plan de cette partie :

1. Généralités

Les trois types de programmes :

  1. Les programmes qui ne communiquent pas avec les utilisateurs (contrôles de processus)

  2. Les programmes qui communiquent de façon indirecte (batch)

  3. Les programmes interactifs (ceux qui nous intéressent :-)

Les types d’IHM :

  • Les IHM orientées texte : TUI (Text User Interface). Sur Mainframes ou Unix essentiellement.

  • Les IHM orientées fenêtres : GUI (Graphic User Interface). Sous Windows, Mac-OS …

  • Les IHM orientées pages : PUI (Page User Interface). Internet, Intranet, Extranet (HTML ou XML)

  • Les IHM Multimodales : vocales, tactiles …

2. Le modèle conceptuel d’IHM – Le SNI

Il n’existe pas de modèle de description d’IHM en UML ou en Merise. Nous allons donc voir le SNI de la méthode MACAO.

2.1. Objet

Le SNI permet de concevoir et de modéliser la logique d’enchaînement des fonctions de l’application en fonction du comportement supposé de l’utilisateur.

Le SNI est purement conceptuel :

  • il est indépendant du type d’interface utilisé (Windows, WEB, Multimédia…)

  • il ne représente pas la manière de faire de l’utilisateur (menu déroulant, bouton, glisser-déposer…)

  • il fait abstraction de tout aspect matériel (clavier, type d’écran, souris…)

  • il ne représente pas les traitements réalisés dans l’application

2.2. SNI et MVC

Le SNI concerne de la partie "Vue" du MVC.

2.3. Les Unités de Dialogue

On appellera "Unité de Dialogue" (UD) l’ensemble des fonctions offertes à l’utilisateur de façon simultanée (sur un même écran, dans une même fenêtre, dans une même page).

Chaque UD est représentée par un ou plusieurs symboles dans le SNI.

Note

Une UD élémentaire = un seul symbole
Une UD composée = plusieurs symboles

2.3.1. Les UD élémentaires (UDE)

sni-ude
Figure 10. Les UDE
Exemple
Figure 11. Exemple d’UDE
Exemple
Figure 12. Autre exemple d’UDE

2.3.2. Les UD composées par juxtaposition (UDC)

Les UD composées par juxtaposition
Figure 13. Les UD composées par juxtaposition
Exemple
Figure 14. Exemple d’UDC

2.3.3. Les UD composées par boîte de groupage (UDC)

Les UD composées par boîte de groupage
Figure 15. Les UD composées par boîte de groupage

2.4. Construction du Schéma Navigationnel d’IHM (SNI)

Deux modes de construction

  • Mode esquisse (construction progressive)

  • Mode conception (construction structurée)

2.4.1. Règles communes

Tip
Règles des retours implicites

Après une UDE, le retour implicite s’effectue sur l’UD précédente. Après une option d’un menu juxtaposé à une UD (élémentaire ou composée) le retour implicite s’effectue sur l’UD juxtaposée.
Tip
Filtres associés aux listes

Permet de restreindre le nombre de lignes d’une liste.
Un filtre porte sur certains attributs de la classe (présents ou non dans la liste).
Filtre
Figure 16. Exemple de filtre
Tip
Tris multiples des listes

Permet de trier une liste de différentes façons.
Les différents tris possibles sont indiqués comme pour un filtre.
tri
Figure 17. Exemple de tri
Tip
Rôles et conditions d’accès

Les rôles et les conditions d’accès permettent de contraindre les accès aux menus ([Rôle,…] ou [-Rôle,…], [valeur > 1000]).

2.4.2. Construction du SNI en mode esquisse

Au cours de l’acquisition des exigences ou

En rétro-conception d’IHM :

  • A partir des besoins des utilisateurs "

    • Cas d’utilisation et fonctions

    • Droits et conditions d’accès

    • Contraintes diverses

  • Participation des utilisateurs

2.4.3. Construction structurée (patrons d’IHM)

  • Pour les applications importantes

  • Adoption du principe OBJET-ACTION

    • Dans une approche objet-action on demande en premier lieu à l’utilisateur d’indiquer quels sont les objets sur lesquels il désire travailler puis, quelles opérations il veut leur appliquer.

  • Exemple d’illustration :

    • Soit une base de données comportant trois types d‘objets : CLIENTS, PRODUITS, FOURNISSEURS

    • L’utilisateur désire effectuer trois types d’actions générales sur ces objets : CONSULTER, MODIFIER, SUPPRIMER

    • Il désire également réaliser trois traitements spécifiques :

      • Lister les clients triés par régions,

      • Imprimer la fiche de stock d’un produit donné,

      • Marquer tous les fournisseurs dont le chiffre d’affaires est < 1000 €

Approche Action-Objet
Figure 18. Approche Action-Objet
Approche Objet-Action
Figure 19. Approche Objet-Action

2.4.4. Mise en oeuvre du principe OBJET-ACTION

Démarche

  • On part du diagramme des classes métier

    • Classes et attributs

    • Relations (associations, compositions, spécialisations)

    • Méthodes utilisateur

  • Utilisation de patrons de conception (Design Patterns)

Le SNI obtenu représente alors le squelette du SNI final.

  • Le squelette est complété avec

    • Les filtres

    • Les droits et conditions d’accès

    • L’accès aux fonctions

  • Le SNI est optimisé en cherchant à minimiser le nombre d’actions utilisateur (clics souris)

Exemple

Les exigences :

  • Afficher la liste de tous les étudiants classés par année, groupe et ordre alphabétique

  • Imprimer la liste

  • Afficher le détail d’un étudiant

  • Modifier l'étudiant affiché

SNI de départ

Complément 1 : Nouveaux étudiants et Constitution groupes

Complément de SNI

Complément 2 : Gestion complète des groupes

Complément de SNI

Complément 3 : Saisie des notes d’un partiel

Complément de SNI

2.4.5. Patrons d’IHM

Cinq patrons d’IHM obtenus à partir du diagramme des classes

  1. Racine (classes ciblées)

  2. Détail (sélection d’un objet dans une liste d’objets)

  3. Liaison (association entre plusieurs classes)

  4. Aiguillage (spécialisation-généralisation)

  5. Administration (mise à jour, création, suppression d’objets)

Patron Racine (classes ciblées)

  • Ciblage des classes métier

  • Mettre en évidence les classes prépondérantes, dont les objets seront présentés au premier niveau de l’IHM

Patron Racine
Patron Détail (sélection d’un objet dans une liste d’objets)

  • Représenter tous les attributs d’un objet désigné dans une liste.

Patron Détail Patron Détail avec Fils

Patron Liaison (association entre plusieurs classes)

  • Suivre les liens entre les objets appartenant à des classes liées par des associations multiples (*)

Patron Liaison Patron Liaison avec classe-association

Patron Aiguillage (spécialisation-généralisation)

  • utile pour présenter les détails d’une généralisation

Patron Aiguillage Patron Aiguillage

Patron Administration (mise à jour, création, suppression d’objets)

  • utile pour matérialiser un CRUD limité à l’administrateur

Patron Admin

3. Les IHM orientées fenêtres (GUI) – Le SEF

Cette partie, réalisée en 1ère année de DUT en 2011/2012, n’est pas encore intégrée à ce support. Elle est proche du [SEP].

4. Les IHM orientées page (PUI) – Le SEP

Ni Merise ni UML n’ont de schémas spécifiques pour représenter les interfaces graphiques, ni les enchaînements des pages dans un site web par exemple. On peut par exemple utiliser un diagramme d'état UML où chaque état est une page et les transitions représentent les événements qui font passer d’une page à l’autre.

La méthode MACAO, déjà évoquée introduit plusieurs schémas utiles à cet effet, que nous allons reprendre dans ce cours. Le livre de Pascal Roques [Roques2007a] reprend par exemple ce genre de diagramme dans sa démarche globale de conception de site web.

Le SEP (Schéma d’Enchaînement des Pages) que nous voyons ici complète le SNI vu précédemment (cf. SNI).

4.1. Concepts des PUI

On peut distinguer 4 types de pages :

  • Pages de cadres

  • Pages de présentation constantes

  • Pages de présentation variables

  • Pages de formulaires

4.1.1. Pages de cadres (Frameset)

Un cadre est un découpage rectangulaire pouvant accueillir une page HTML (y compris une autre page de cadres).

Une page de cadre est divisée en deux ou plusieurs cadres occupant la totalité de la page.

Figure 20. Exemples de cadres

4.1.2. Pages de présentation constantes

Pages ne contenant que des objets visuels constants statiques et des objets de navigation :

  • boutons d’action

  • zones réactives

  • liens hypertextes

Note

Pages rencontrées habituellement en surfant sur le Net.

4.1.3. Pages de présentation variables (ou pages dynamiques)

Analogues aux précédentes mais comportant en plus des données variables obtenues par calcul ou lues dans des fichiers ou des bases de données.

Méthodes d’obtention :

  • CGI (Common Gateway Interface),

  • ASP (Active Server Pages) de Microsoft, PHP d’Open Source

  • OAS (Oracle Application Server)

  • JSP (Java Server Page)

  • Servlet Java

  • …

4.1.4. Pages de formulaires

Pages contenant des objets de saisie (équivalentes aux boîtes de dialogue de saisie)

  • zones de textes (champs d’entrée)

  • boutons radios, cases à cocher

  • listes déroulantes

Figure 21. Exemple de formulaire

4.1.5. Les types d’objets visuels

Une page peut contenir 3 catégories d’objets :

  • Objets de positionnement

  • Objets non référencés

  • Objets référencés

Les objets de positionnement

Ils permettent d’indiquer les zones d’interaction avec l’utilisateur.

On trouve :

  • le cadre ne pouvant apparaître que dans une page de cadres

  • le signet (ou ancre d’arrivée) indiquant un point de chute possible dans une page

  • les objets de présentation et de mise en page : tableaux <TR>, <TD>, divisions de pages <DIV>…

Les objets non référencés

Ils ne sont utilisés que pour les affichages statiques et n’ont pas besoin d'être identifiés de façon précise.

On trouve :

  • les statiques fixes : textes (ou labels), images (gif, jpeg…), encadrements, figures géométriques

  • les statiques animés : textes défilants, images animées (gif animé, vectorielles de type Flash…) scènes vidéo (mpeg, avi…), séquences audio (wav, mp3…)

Les objets référencés

Ils permettent d’assurer les interactions utilisateur : actions, saisie, navigation

On trouve :

  • les objets actifs de navigation : boutons d’actions simples ou sensitifs, liens vers les autres pages, liens hypertextes vers des URL (Uniform Resource Locator) ou des signets, zones réactives, zones de courrier électronique

  • les contrôles de formulaires : boutons (d’action, case à cocher, radio), champ d’entrée (simple, multilignes, de mot de passe), listbox (simple ou déroulante)

4.2. Principes ergonomiques

Cette partie fait l’objet dans le cours de DUT d’une intervention particulière, par une professionnelle de l'érgonomie. Nous reprenons simplement ici quelques grands principes.

Règle d'ergonomie : Utilisation des divisions

Utilisez des divisions pour placer les informations répétées sur plusieurs pages : menus, en-têtes…

Règle d'ergonomie : Affichage des listes de résultats

Utilisez des tableaux plutôt que des listes déroulantes

Règle d'ergonomie : Structure des formulaires

Les règles de structuration des boîtes de dialogue sont applicables la plupart du temps (alignement des champs affichés, regroupement des contrôles par famille, …)

Règle d'ergonomie : Contrôles de saisie

Effectuez les « contrôles de surface » en local (fonction javascript par exemple)

Règle d'ergonomie : Polices et couleurs

Utilisez des polices standard (Arial, Times, Verdana)
Utilisez plutôt des fonds de pages clairs et une écriture sombre

Règle d'ergonomie : Styles

Utilisez des feuilles de styles (CSS) pour les polices et les balises de présentations de textes : <A>, <H1>…

4.3. Le SEP

4.3.1. Codification

Figure 22. Codification des types d’objets visuels nommés
Figure 23. Codification des types d’objets visuels nommés (suite)
Figure 24. Représentation des pages

Caractéristiques générales :

  • Nom de la page précédé de son type : PCA, PPC, PPV, PFO

  • [ Droit d’accès ] ou [ Condition ]

  • "DESSIN", "MAQUETTE" ou "DESCRIPTIF" pour les pages complexes

  • ( Paramètres ) : paramètre obligatoire souligné

  • FILTRE : <valeur du filtre> ; TRI : <attributs et sens>

  • CADRE : <nom du cadre d’accueil>

  • "FENETRE" si la page doit s’ouvrir dans un autre fenêtre navigateur

  • "POPUP" si la page doit s’ouvrir dans une fenêtre popup

4.3.2. Exemples de pages

Figure 25. Page de cadres avec deux cadres
Figure 26. Page de présentation variable
Figure 27. Page de présentation constante
Figure 28. Page de formulaire

4.3.3. Construction du SEP à partir du SNI

Figure 29. Le SNI de départ
Figure 30. Le SEP résultant

4.4. Dessin des pages complexes

4.4.1. Généralités

Figure 31. Notation pour les dessins de pages

4.4.2. Formulaires

Figure 32. Boutons
Figure 33. Saisie
Figure 34. Liste
Figure 35. Liens
Figure 36. Tableau

4.4.3. Exemples

Figure 37. Détail compte
Figure 38. Saisie Note

4.5. Les dessins complexes

Un certain nombre d’outils existent pour faire des dessins complexes. Le prototypage rapide d’interface graphique est important pour valider au plus tôt les besoins du client (au moins en terme d’interface).

Figure 39. Un exemple de "mockup" réalisé avec l’outil balsamiq

Nous n’en donnons que quelques-uns ici.

Partie 7 : Génie Logiciel

Partie 8 : UML Avancé

Dans cette partie, nous allons aborder une démarche générale de conception. Nous allons aborder des diagrammes UML comme le diagramme des cas d’utilisation ou de séquences. Dans nos enseignements de DUT Informatique, cette partie est abordée en 3ème semestre.

n’est donné ici qu'à titre d’exemple. Aucune démarche n’est associée à UML et nous faisons une agrégation ici des meilleures pratiques entre UML et Merise.

Pour continuer avec l’image de l’architecte, il s’agit pour lui de s’assurer, par une démarche systématique, du succès de son projet.

Plan de cette partie :

1. Le Diagramme des Cas d’Utilisation

Le Diagramme des Cas d’Utilisation est un modèle UML permettant de représenter :

  • les UC (Use Case ou Cas d’Utilisation)

  • les acteurs (principaux et secondaires)

  • les relations entre acteurs et UC

Note

On notera simplement UC pour signifier "diagramme des UC"

1.1. Définition et concepts

1.1.1. Cas d’Utilisation (Use Case ou UC en abrégé).

Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.

Exemple d’UC

Retrait par carte bancaire

Scénario principal

L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.

Scénario alternatif n°1

Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.

Exemple de codification de l’UC

UC01 ou RetraitCB (pour Retrait par carte bleue)

Précisions

Un cas d’utilisation peut être précisé par :

  • une description textuelle

  • un ou des diagrammes UML (séquence, activité)

Note

Dans les outils, cette "précision" se manifeste par le fait que l’on "attache" généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un UC → nouveau seq).

1.1.2. Acteur

Un acteur peut être une personne, un ensemble de personnes, un logiciel, un processus qui interagit avec un ou plusieurs UC.

On peut trouver plusieurs types d’acteurs :

  • extérieurs au système (cf. actor Diagramme d’UC ci-après)

    • les acteurs principaux (= acteurs internes du MOT de Merise)

    • les acteurs secondaires (= acteurs externes du MOT de Merise)

    • les administrateurs (ils gèrent le système : données, sécurité, droits d’accès, utilisateurs…)

  • types d’acteurs prédéfinis dans UML :

    • <<metaclass>>

    • <<utility>>

    • <<process>>

    • <<thread>>

    • <<powertype>>

1.1.3. Relations entre UC

Extension (<<extend>>)

Indique que l’UC source est éventuellement exécutée en complément de l’UC destination (cas particulier, erreur…)

Inclusion (<<include>>)

Indique qu’un UC est inclus obligatoirement dans un autre UC (notion de sous-programme par exemple)

Généralisation

Relation entre un UC général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute

Figure 40. Notation dans le diagramme d’UC
Tip

On n’utilise généralement <<include>> que dans le cas où le sous-cas d’utilisation est inclut dans plusieurs UC. Si ce n’est pas le cas, il est généralement englobé dans l’UC.

1.2. Pour construire un UC (de manière générale)

  1. identifier les acteurs

  2. identifier les cas d’utilisation

  3. structurer en packages

  4. ajouter les relations

  5. finaliser les diagrammes de cas d’utilisation

1.3. Obtention des UC dans le cadre de ce cours

Deux cas peuvent se présenter :

Un nouveau MOT a été construit

Chaque tâche informatique du nouveau MOT devient un UC

Un MOT n’a pas été nécessaire

Les cas d’utilisation doivent directement être extraits des interviews d’utilisateurs ou des compte-rendus de réunions (cf. cas général ci-dessus).

1.4. Exemples complets

1.4.1. Service comptable

Exemple de Diagramme d'UC
Figure 41. Exemple de diagramme d’UC

1.4.2. Gestion des notes

Exemple de Diagramme d'UC
Figure 42. Autre exemple de diagramme d’UC

1.4.3. Liens entre SNI et UC

Lien entre UC et SNI

2. Opérations, Paquetages et Java

2.1. Opérations

Un ensemble d’opérations définit le comportement de l’objet (ex : setVitesse(valeur)), c’est à dire son interface.

Exemple de classe avec opération
Figure 43. Exemple de classe avec opération
Opérations et objet
Figure 44. Opération et objet

2.2. Opérations et Visibilité

L'encapsulation

  • facilite l'évolution d’une application car elle stabilise l’utilisation des objets. On peut modifier l’implémentation des attributs d’un objet sans modifier son interface

  • garantit l’intégrité des données, car elle permet d’interdire l’accès direct aux attributs des objets (utilisation d’accesseurs). Un objet n’est manipulable qu’à travers son interface

Tip

Rappel : chaque opération a un argument implicite qui est l’objet sur lequel elle porte.
Int getKilometrage( );

Exemple : varKm = v2.getKilometrage( );
Type d’opérations

Un accesseur getX() permet de consulter l’attribut X de l’objet, le modificateur setX(val) permet de modifier la valeur de l’attribut X avec le paramètre val. Par défaut, on doit avoir un accesseur par attribut privé.

Visibilité

Il existe 4 niveaux de visibilité des attributs et des opérations :

  • - privé (l’élément n’est visible que par la classe)

  • + public (l’élément est visible par toutes les autres classes)

  • # protégé (l’élément est visible par la classe et ses sous-classes)

  • ~ package (l’élément est visible par la classe et les classes du même paquetage)

2.3. Paquetages

Les paquetages permettent de regrouper les éléments de modélisation. Ils peuvent contenir d’autres sous-paquetages sans limites de niveaux.

Le paquetage est un espace de nommage.

Un paquetage peut importer une classe issue d’un autre paquetage.

Exemple : Vehicules::Voitures signifie que la classe Voiture est importée du paquetage Vehicules.

Dépendances entre packages
Figure 45. Dépendances entre packages
Note

On emploiera souvent dans ce cours le terme anglais de package pour désigner un paquetage.

2.4. Génération de code

Voici quelques exemples de diagramme de classes et du code java associé.

2.4.1. Classe

Une classe
Figure 46. La classe Catalogue du package Catalogue
package Catalogue;
import java.util.Date;

public class Catalogue {
        private String nom;
        private Date dateCreation;

        public Catalogue() {
                ...
        }

        public Livre chercherLivre(String isbn) {
                ...
        }
}

2.4.2. Généralisation

Généralisation
Figure 47. La classe Adherent hérite de Personne
public abstract class Personne {
        private String nom;
        private String prenom;
        protected Date dateNaissance;
        private static int ageMajorite = 18;
        public abstract int calculerDureePret() {... }
        public static void setAgeMajorite (int aMaj) {... }
}

public class Adherent extends Personne {
        private int iD;

        public Adherent() { ... }
        public int getAge() { ... }
        public int calculerDureePret() { ... }
}

2.4.3. Associations

Associations
Figure 48. Associations
public class A1 {
        private B1 leB1;
}
public class A2 {
        private B2 lesB2[ ];
}
public class A3 {
        private List lesB3 = new ArrayList();
}

2.4.4. Dépendance

Dépendance
Figure 49. Dépendance
package Bibliotheque;
import Catalogue;

public class Bibliotheque {
        private Catalogue leCatalogue;
        ...
}

2.4.5. Equivalences entre diagramme de classes

Equivalences
Figure 50. Equivalences

2.4.6. Classe Association

Classe Association
Figure 51. Classe Association
public class Emploi {
        private String titre
        private Double salaire;
        private Employe salarie;
        private Societe employeur;
        ...
}

3. Le Diagramme de Séquence

3.1. Généralités

  • Modélise les interactions entre objets

  • Séquencement dans le temps

  • Échange de messages

  • Spécifie les scénarios des cas d'études

  • Éléments :

    • participants

    • lignes de vie

    • barres d’activation

    • messages

Diagramme de séquence

Diagramme de séquence Eléments de notation

Warning

Les lignes de vie représentent des objets et non des classes

3.2. Exemple

Exemple de diagramme de séquence
Figure 52. Exemple de diagramme de séquence

3.3. Notions avancées

  • Instructions itératives et conditionnelles

  • Mieux vaut utiliser un diagramme d’activité

  • Cadres d’interaction

    • loop (boucle)

    • alt (alternative)

    • opt (optionel)

    • par (parallèle)

    • region (région critique - un seul thread à la fois)

Exemple algorithme / diagramme

Un algorithme Sa modélisation

3.4. Exemple de conceptions

Conception 'centralisée'
Figure 53. Conception "centralisée"
Conception 'objet'
Figure 54. Conception "objet"

3.5. Diagramme de séquence système

Bien que non présent dans UML, il est courant de trouver un diagramme de séquence particulier, le diagramme de séquence système ou DSS, où on ne représente qu’un seul objet : le système en cours de développement lui-même.

Exemple de DSS
Figure 55. Un exemple de DSS

3.6. Lien entre UC, DSS et DS

La décomposition hiérarchique permet de réaliser une description "TOP-DOWN" du système à réaliser.

On fait un Diagramme de Séquence Système pour chaque UC (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.

Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les objets composants le système (issus du Diagramme de Classes) collaborent pour réaliser le traitement demandé.

Diagramme d'UC
Figure 56. Diagramme d’UC
Le DSS correspondant
Figure 57. Le DSS correspondant
Le DS correspondant
Figure 58. Le DS correspondant

4. Le paradigme MVC

Le paradigme Modèle-Vue-Contrôleur, ou MVC (de l’anglais Model-View-Controller) est une architecture logicielle qui divise l’application en trois éléments importants (cf. MVC ci-dessous) :

le modèle

chargé de gérer les élements d’information (comme la base de donnée)

les vues

interfaces entre l’application et l’utilisateur

les contrôleurs

chargés de faire le lien entre vues et modèle.

L’avantage de ce patron d’architecture :

  • la clarté qu’il impose,

  • la simplification de maintenance du logiciel. La modification d’une partie (vue, modèle ou contrôleur) n’affecte pas ou peu les autres parties.

Note

Le MVC est issu d’un modèle de programmation des applications interactives proposé par Xerox pour le langage Smalltalk-80, repris par SUN et recommandé pour la plateforme J2EE.

La vue correspond à l’interface avec laquelle l’utilisateur interagit. Sa tâche est :

  • de présenter les résultats renvoyés

  • de recevoir toutes les actions de l’utilisateur (clic de souris, sélection d’une entrée, boutons, …)

Ces différents événements sont envoyés au contrôleur.

Le contrôleur gère les événements pour mettre à jour la vue ou le modèle et les synchroniser.
Il reçoit tous les événements de l’utilisateur et enclenche les actions à effectuer.

Figure 59. Séparation des préoccupations dans le MVC
Note

Le modèle contient les données manipulées par l’application.
Il gère ces données et garantit leur intégrité.
Il offre des méthodes pour mettre à jour ces données.
Il correspond généralement au diagramme des classes métiers.
Note

Il y a en général un contrôleur par UC.
Note

Les 3 packages présentés ci-dessus (cf. MVC regrouperont respectivement
les classes d’IHM (View)+ les classes contrôlleurs (une par UC - Controler)
les classes métiers (Model)

4.1. Exemple

Figure 60. Diagramme de classe
Figure 61. Diagramme des UC
Figure 62. Diagramme des classes contrôlleurs
Figure 63. Diagramme des classes vues
Figure 64. Diagramme de Séquence Système
Figure 65. Un Diagramme de Séquence

4.2. Le Diagramme des Classes Participantes

Il s’agit des classes, issues des 3 paquetages MVC, qui "participent", dans un DS donné, à la réalisation d’un UC. On fait notamment apparaître les méthodes utilisées par le DS dans chaque classe.

Figure 66. Un exemple de Diagramme de Classe Participante

4.3. Les MVC

En fonction des langages et des architectures, vous trouverez autant de schéma MVC différents que l’on peut en imaginer! Attention à vous adaptez.

Figure 67. La jungle des modèles MVC (petit extrait d’une recherche sur le web!)

Cette partie est traitée ici.

5. Les Dessins d’Etats imprimés

5.1. Objet

Les états informatiques doivent faire l’objet d’une analyse précise avant de procéder à leur programmation.

Dans ce but on utilise une grille d’imprimante (ou grille d’impression).

Cette grille est remplie à partir d’une maquette utilisateur (dessin rapide permettant de capter les besoins de l’utilisateur)

Le report de la maquette utilisateur sur une grille d’imprimante permet de réaliser une mise à l'échelle de l'état et de donner des instructions précises au programmeur.

Figure 68. Exemple de grille

5.2. Les familles d’imprimantes

5.2.1. Les imprimantes lignes

Elles sont généralement utilisées dans les grands centres d’impression.

L’impression est réalisée ligne par ligne avec un format fixe sur du papier en continu (pliage accordéon) muni de bandes d’entraînements latérales appelées bandes Carol.

Caractères utilisés : très limités (26 lettres et 10 chiffres et qq caractères spéciaux) Vitesse : en lignes par minutes. Elle peut varier de 200 à 2000 lpm.

5.2.2. Les imprimantes matricielles (ou à aiguilles)

Ces imprimantes fonctionnent avec une colonne d’aiguilles (9, 12, 24 … aiguilles) permettant d’imprimer les caractères sous forme d’un ensemble de points. Les aiguilles sont placées dans une tête d’écriture se déplaçant latéralement devant le papier.

Caract. utilisés : formes et tailles variées ainsi que mise en relief (gras, souligné, italique).

Vitesse : en cps (Caractères Par Seconde). Elle varie de 60 à 400 cps.

5.2.3. Les imprimantes à jet d’encre

Elles utilisent les mêmes principes que les imprimantes à aiguilles mais les aiguilles sont remplacées par une série de buses projetant un jet d’encre sur le papier : plus de silence et meilleure qualité d’impression.

5.2.4. Les imprimantes laser

Un rayon laser magnétise localement un tambour sur lequel est projetée une encre en poudre. L’encre est attirée par les régions magnétisées du tambour et se dépose sur le papier sur lequel elle est fixée par chauffage. Les imprimantes laser impriment directement une page complète.

Les caractères : tous

Vitesse : en ppm (Page Par Minute). 10 ppm environ

5.3. Les formulaires en continu

5.3.1. Les liasses

On appelle liasse une superposition de plusieurs feuilles de papier chimique (de 2 à 4) permettant d’imprimer simultanément plusieurs exemplaires d’un même état. Les liasses ne peuvent être utilisées qu’avec les imprimantes lignes ou matricielles (qui « frappent » le papier).

5.3.2. Les pré-imprimés

Certaines informations apparaissant sur les états peuvent être- pré- imprimées par un imprimeur (à partir d’une maquette qu’on lui aura fournie).

Caractéristiques du pré-imprimé :

  • + meilleure qualité d’impression

  • + temps d’impression réduit

  • - coût du papier plus important

5.4. La grille d’imprimante

5.4.1. Types d’informations

Il faut distinguer deux types d’informations apparaissant sur un état, les informations fixes et les zones variables.

Les informations fixes

Elles correspondent aux différents titres et encadrements. Les informations pré-imprimées sont forcément des informations fixes (on les représentera en rouge sur la grille d’impression).

Les zones variables (3 catégories)

les zones alphanumériques : format COBOL X(n)
les zones numériques entières :format COBOL 9(n)
les zones décimales avec séparateur : 9(n)V,9(m)

Chaque caractère, fixe ou variable, occupera une case de la grille d’imprimante.

5.4.2. Graphisme "ancien"

Utilisation d’étoiles, de i majuscules et de tirets :

5.5. Présentation générale des états

Il faut prévoir l’impression de la date d'édition de l'état (en haut à gauche). Dans le cas de listes se poursuivant sur plusieurs pages on rajoutera systématiquement les informations suivantes :

  • un num. de page en haut à droite, avec le nb total de pages (ex : 3/10)

  • une répétition des titres en haut de chaque page

Il faudra veiller à imposer des sauts de page (FF : Form Feed) à certains endroits.

5.5.1. Répétition de lignes et de blocs :

Si une ligne de variable se répète de façon identique sur plusieurs lignes, on indiquera la répétition en plaçant sous chaque variable une colonne de points. Des répétitions de blocs de lignes seront représentées par des accolades.

5.5.2. Numérotation des variables et légende :

De façon à ce que le programmeur puisse identifier correctement chaque variable, on procédera à leur numérotation de gauche à droite et de haut en bas sur la grille d’imprimante.

Le numéro sera porté au-dessus de chaque zone variable en utilisant une couleur différente de façon à ne pas les assimiler aux informations fixes.

Seules les variables de la première ligne seront numérotées si la ligne est répétitive.

Les numéros de variables seront reportés dans une légende qui sera placée sur la grille d’imprimante s’il y a de la place ou sur une feuille jointe. La légende portera les informations suivantes : numéro et nom de la variable, format d'édition COBOL.

6. Rappels sur les démarches

6.1. Généralités

Les grandes étapes :

  • Analyser

  • … puis Concevoir

  • … … puis Réaliser

Deux grandes écoles :

  • Projets en cascade

    • Analyse

    • Conception

    • Réalisation

  • Projets itératifs

    • Prototypage

    • Contrat de moyens et non de résultats

    • Liens MOA/MOE plus compliqués (cf. plus loin)

6.1.1. Analyser

  • Découvrir/décortiquer un domaine

  • Prendre en compte les besoins utilisateurs

  • Définir le problème à résoudre

    • Fonctionnalités

    • Qualités attendues

    • Environnement

  • Modéliser le tout

6.1.2. Concevoir

  • Définir une solution :

    • Structurer les données

    • Organiser les traitements

    • Définir les postes de travail

    • Adopter certaines techniques

6.1.3. Réaliser

  • Coder

  • Recoder une application existante (Refactoring)

6.1.4. Qualités requises

  • Pour bien analyser et concevoir :

    • Avoir une bonne capacité d’abstraction

    • Maîtriser la modélisation

      • Abstraire

      • Communiquer

    • Qualités relationnelles

    • Etre créatif

    • Avoir de la méthode

6.1.5. Rôles importants

Deux acteurs importants :

  • Maîtrise d’ouvrage (MOA)

  • Maîtrise d’oeuvre (MOE)

Note
Définis par la loi! (n° 85-704 du 12 juillet 1985)

Le maître de l’ouvrage est la personne morale, …, pour laquelle l’ouvrage est construit. Responsable principal de l’ouvrage, il remplit dans ce rôle une fonction d’intérêt général dont il ne peut se démettre. Il lui appartient, après s'être assuré de la faisabilité et de l’opportunité de l’opération envisagée, d’en déterminer la localisation, d’en définir le programme, d’en arrêter l’enveloppe financière prévisionnelle, d’en assurer le financement, de choisir le processus selon lequel l’ouvrage sera réalisé et de conclure, avec les maîtres d’oeuvre et entrepreneurs qu’il choisit, les contrats ayant pour objet les études et l’exécution des travaux.

6.1.6. Analyser, c’est difficile

Service de vente en ligne (jeBouquine.com)

Analyser, c'est difficile
Analyser, c'est difficile
Analyser, c'est difficile
Analyser, c'est difficile
Analyser, c'est difficile
Analyser, c'est difficile

6.2. Exemple complet de démarche "ad hoc" autour d’UML

Nous allons aborder une étude de cas tirée du livre de Pascal Roques.

Note

Pour un apperçu du livre, cf. http://www.editions-eyrolles.com/Chapitres/9782212110708/chap01.pdf.

6.2.1. Le cahier des charges

Il s’agit de développer un service de vente en ligne (http://jeBouquine.com).

6.2.2. Des besoins au code

(c) Pascal Roques
Figure 69. Le gap à combler (image tirée de [Roques2007a])

6.2.3. Raffinement des besoins

(c) Pascal Roques
Figure 70. Raffinement des besoins (image tirée de [Roques2007a])

6.2.4. Près du code

(c) Pascal Roques
Figure 71. Près du code (image tirée de [Roques2007a])

6.2.5. Comment trouver les classes ?

(c) Pascal Roques
Figure 72. Comment trouver les classes ? (image tirée de [Roques2007a])

6.2.6. Comment trouver les interactions ?

(c) Pascal Roques
Figure 73. Comment trouver les interactions ? (image tirée de [Roques2007a])

6.2.7. Liens entre diagrammes

(c) Pascal Roques
Figure 74. Liens entre diagrammes (image tirée de [Roques2007a])

6.2.8. Démarche complète

(c) Pascal Roques
Figure 75. Démarche complète (image tirée de [Roques2007a])

6.3. Exemple d’une méthode industrielle

Nous allons rapidement survoler la méthode Neptune. Développée en collaboration avec des académiques (dont l’IRIT et des industriels (dont Communication & System), cette méthode couvre aussi bien le business model (modèle orienté "économique" qui aborde aussi bien le produit que des notions comme les objectifs, les opportunités, les processus, etc.) que le génie logiciel (software engineering) qui nous intéresse ici.

Note

La méthode Neptune tire ses racines du Unified Process (cf. [RUP]). Elle est compatible avec la méthode de Pierre-Alain Muller (cf. [Muller]). Elle est supportée par un outil eclipse. Pour plus d’information, voir http://neptune.irit.fr/.

6.3.1. Démarche globale

Neptune
Figure 76. La démarche globale Neptune
Note

qui utilise le mieux la méthode Neptune. L’an dernier ce prix était de 1.500 €!

Les grandes étapes de la démarche sont :

  • Analyse des besoins (Requirements Analysis)

  • Analyse objet (Object Analysis)

  • Conception architecturale (Architectural Design)

  • Conception objet (Object Design)

  • Conception physique (Physical Design)

Analyse des besoins

L’objectif de cette étape est de définir l’environnement du système et son utilisation.

Plusieurs activités concernent cette phase :

  • Définition des acteurs

  • Définition du contexte

  • Description du système

Analyse objet

L’objectif de cette étape est de commencer à organiser les classes déjà identifiées dans l'étape précédente et d’obtenir une première vue logique du système.

Une seule activité concerne cette phase :

  • Analyse objet

Conception architecturale

L’objectif de cette étape est de définir l’architecture du système.

Plusieurs activités concernent cette phase et se déroulent en parallèle :

  • Définition des composants logiciels

  • Description des composants logiciels

  • Identification des packages de conception

  • Application des patrons de conception (designs patterns)

Conception objet

L’objectif de cette étape est de développer pour chaque package une conception détaillée.

Plusieurs activités concernent cette phase :

  • Conception des classes

  • Mise en oeuvre du MVC et conception des modèles de données

Conception Physique

L’objectif de cette étape est de concevoir l’architecture physique de l’application.

Plusieurs activités concernent cette phase :

  • Description de l’architecture physique

  • Identification des processus et des composants

  • Allocation des classes

6.3.2. Analyse et vérification

L’intérêt de la méthode Neptune réside essentiellement sur le fait qu’elle insiste sur la phase de vérification des modèles. Très détaillée, cette activité dépasse le cadre de ce cours d’introduction.

Note

Pour plus de détail, voir le livre en ligne http://neptune.irit.fr/images/files/NeptuneBook/407719ps.pdf.

6.4. Au DUT Informatique de Blagnac

La démarche que nous utilisons au DUT est résumée par le diagramme ci-dessous.

chez nous
Figure 77. La démarche globale au DUT Info de Blagnac

Appendix A: Annexes

1. Exercices de révision

Reprendre ici les questions des chapitres (à organiser en fichiers!) et également le quizz.

2. Liens utiles

3. A propos de ce document…

Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham. La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert. Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons. Licence Creative Commons licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.

4. FAQ

Cette Frequently Asked Question a été construite par expérience, en regroupant les questions des étudiants durant mes différentes interventions.

Cette FAQ peut servir de base à la révision d’examens.

4.1. Peut-on "séparer" un acteur externe en deux acteurs externes avec un statut différent.

(Par exemple, un acteur "Personne intéressée par l’achat d’un portable" et un autre acteur "Acheteur")

Oui, c’est toujours permis puisque les acteurs sont des rôles et non des personnes bien identifiées. La question qui se pose est : est-ce judicieux? Dans certains diagrammes on pourra restreindre l’usage de telle ou telle partie de l’application à tel ou tel rôle. Donc dans l’exemple ça semble intéressant de différentier (l’acheteur pourrait être identifié avec un login et un num de carte bleue, la personne intéressée ne l'étant pas par exemple, etc.).

4.2. Exemple

4.3. Divers

Quelques autres questions que je laisse à votre sagacité :

  • blabla

4.4. A propos de la production de documents par programmation

blabla …

Bibliographie

Les références…

  • [gram86] Ana Gram. Raisonner pour programmer. Dunod, 1986.

  • [HighsmithFowler2001] Jim Highsmith and Martin Fowler. The agile manifesto. Software Development Magazine, 9(8) :29–30, 2001.

  • [1030005] Kieran Conboy and Brian Fitzgerald. Toward a conceptual framework of agile methods : a study of agility in different disciplines. In WISER ’04 : Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research, pages 37–44, New York, NY, USA, 2004. ACM.

  • [Roques2007a] Les Cahiers du Programmeur, UML2, Pascal Roques 3ème Edition, Eyrolles, 2007.

  • [Roques2007b] UML 2 par la pratique, Pascal Roques 6ème Edition, Eyrolles, 2007.

  • [Blanc2006] UML pour les développeurs, Xavier Blanc, Eyrolles, 2006.

  • [Longepe2006] Le projet d’urbanisation du S.I., C. Longépé, 3ème édition, Dunod, 2006.

  • [Gillet2008] Management des SI, M. & P. Gillet, Dunod, 2008.

  • [Muller] Modélisation objet avec UML. Pierre-Alain Muller & Nathalie Gaetner, Eyrolles, 2003.

  • [RUP] http://fr.wikipedia.org/wiki/Unified_Process

Glossaire

Note
Ressources

Les définitions ci-dessous sont regroupées à titre indicatif. Les sources utilisées sont :
DRY

Don’t Repeat Yourself :

IHM

Interface Homme-Machine

MCF

Modèle Conceptuel des Flux

MCT

Modèle Conceptuel des Traitements

MOA

Maîtrise d’ouvrage (MOA) Maîtrise d’oeuvre (MOE)

MOF

Modèle Organisationnel des Flux

MOT

Modèle Organisationnel des Traitements

OMG

Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).

PPN

Programme Pédagogique National

SEF

Schéma d'Enchaînement des Fenêtres

SEP

Schéma d'Enchaînement des Pages

SNI

Schéma de Navigation d'Interfaces

SysML

System Modeling Language ™ : le langage de modélisation de systèmes maintenu par l’OMG.

TRL

Technology Readiness Level : système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d'évaluer le niveau de maturité d’une technologie (cf. Wikipedia).

URL

Universal Ressource Locator

Index